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Abstract 


The Session Description Protocol (SDP) has been extended with a 
capability negotiation mechanism framework that allows the endpoints 
to negotiate transport protocols and attributes. This framework has 
been extended with a media capabilities negotiation mechanism that 
allows endpoints to negotiate additional media-related capabilities. 
This negotiation is embedded into the widely used SDP offer/answer 
procedures. 


This memo extends the SDP capability negotiation framework to allow 
endpoints to negotiate three additional SDP capabilities. In 
particular, this memo provides a mechanism to negotiate bandwidth 
("b=" line), connection data ("c=" line), and session or media titles 
("i=" line for each session or media). 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7006. 
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Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 

(http: //trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The Session Description Protocol (SDP) [RFC4566] is intended for 
describing multimedia sessions for the purposes of session 
announcement, session invitation, and other forms of multimedia 
session initiation. SDP has been extended with an SDP Capability 
Negotiation Mechanism Framework [RFC5939] that allows the endpoints 
to negotiate capabilities, such as support for the Real-time 
Transport Protocol (RTP) [RFC3550] and the Secure Real-time Transport 
Protocol (SRTP) [RFC3711]. The SDP Media Capabilities Negotiation 
[RFC6871] provides negotiation capabilities to media lines as well. 


The capability negotiation is embedded into the widely used SDP 
offer/answer procedure [RFC3264]. This memo provides the means to 
negotiate further capabilities than those specified in the SDP 
Capability Negotiation Mechanism Framework [RFC5939] and the SDP 


Media Capabilities Negotiation [RFC6871]. In particular, this memo 
provides a mechanism to negotiate bandwidth ("b="), connection data 
("c="), and session or media titles ("i="). 


Since the three added capabilities are independent, it is not 
expected that implementations will necessarily support all of them at 
the same time. Instead, it is expected that applications will choose 
their needed capability for their specific purpose. For this reason, 
the normative part pertaining to each capability is in a self- 
contained section: Section 3.1.1 describes the bandwidth capability 
extension, Section 3.1.2 describes the connection data capability 
extension, and Section 3.1.3 describes the title capability 
extension. Separate SDP Capability Negotiation option tags are 
defined for each capability, allowing endpoints to indicate and/or 
require support for these extensions according to procedures defined 
in SDP Capability Negotiation [RFC5939]. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119] and indicate requirement levels for compliant 
implementations. 
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3. Protocol Description 

3.1. Extensions to SDP 
The SDP Capability Negotiation Framework [RFC5939] and the SDP Media 
Capabilities Negotiation [RFC6871] specify attributes for negotiating 
SDP capabilities. These documents specify new attributes (e.g., 
"acap", "tcap", "rmcap", and "omcap") for achieving their purpose. 
In this document, we define three new additional capability 
attributes for SDP lines of the general form: 


type=value 


for types "b", "c", and "i". The corresponding capability attributes 
are respectively defined as: 


o "“bcap": bandwidth capability 
o "“ccap": connection data capability 
o "icap": title capability 


From the sub-rules of the attribute ("a=") line in SDP [RFC4566], SDP 
attributes are of the form: 


attribute = (att-field ":" att-value) / att-field 
att-field token 
att-value byte-string 


Capability attributes use only the "att-field:att-value" form. 


The new capabilities may be referenced in potential configurations 
("a=pcfg") or in latent configurations ("a=lcfg") as productions 
conforming to the <extension-config-list>, as respectively defined in 
RFC 5939 [RFC5939] and RFC 6871 [RFC6871]. 


extension-config-list = ["+"] ext-cap-name "=" ext-cap-list 
ext-cap-name = 1*(ALPHA / DIGIT) 

; ALPHA and DIGIT defined in RFC 5234 
ext-cap-list = 1*VCHAR ; VCHAR defined in RFC 5234 


The optional "+" is used to indicate that the extension is mandatory 
and MUST be supported in order to use that particular configuration. 
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The new capabilities may also be referenced in actual configurations 
("a=acfg") as productions conforming to the <sel-extension-config> 
defined in RFC 5939 [RFC5939]. 


sel-extension-config = ext-cap-name "=" 1*VCHAR 


The specific parameters are defined in the individual description of 
each capability below. 


The "bcap", "ccap", and "icap" capability attributes can be provided 
at the SDP session and/or media level. According to the SDP 
Capability Negotiation [RFC5939], each extension capability must 
specify the implication of making it part of a configuration at the 
media level. 


According to SDP [RFC4566], "b=", "c=", and "i=" lines may appear at 
either session or media level. In line with this, the "bcap", 
"ccap", and "icap" capability attributes, when declared at session 
level, are to be interpreted as if that attribute was provided with 
that value at the session level. The "bcap", "ccap", and "icap" 
capability attributes declared at media level are to be interpreted 
as if that capability attribute was declared at the media level. 


For example, extending the example in [RFC6871] with "icap" and 
"bcap" capability attributes, we get the following SDP: 


v=0 

o=- 25678 753849 IN IP4 192.0.2.1 
s= 

c=IN IP4 192.0.2.1 

t=0 0 


a=bcap:1 CT:200 

a=icap:1 Video conference 
m=audio 54320 RTP/AVP 0 
a=rmcap:1 116/8000/1 

a=rmcap:2 L16/16000/2 

a=pcfg:1 m=1|2 pt=1:99,2:98 
m=video 66544 RTP/AVP 100 
a=rmcap:3 H263-1998/90000 
a=rtpmap:100 H264/90000 
a=pcfg:10 m=3 pt=3:101 b=1 i=1 


Figure 1: Example SDP offer with bcap and icap 
efined at session level 
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The above SDP defines one PCMU audio stream and one H.264 video 


stream. 
numbered 1 and 2), 
kbps, respectively, 


H.263 video ("rmcap" numbered 


all appear at the media level. 


bandwidth capability ("bcap") 


both defined at session level. 


when the capabilities defined 
referenced from the potential 
they are to be interpreted as 


It also defines two RTP-based media capabilities 
using 16-bit linear 
as well as an RTP-based media capability for 


("rmcap" 


(L16) audio at 8 kbps and 16 


3). The RTP-based 
The example also 


media capabilities 

contains a single 

and a single title capability ("icap"), 
According to the definition above, 

in the "bcap" and "icap" attributes are 

configuration, in the resulting SDP 

session-level attributes (but the 


RTP-based media capabilities are to be interpreted as media-level 


attributes). 


dd 


Bandwidth Capability 


According to RFC 4566 


specified in RFC 4566 


b=<bwt ype> : <bandwidth> 


[RFC4566], 
proposed bandwidth to be used by the session or media. 
we specify the bandwidth capability attribute, 
at the SDP session and/or media level. 


the bandwidth field denotes the 

In this memo, 
which can also appear 
The bandwidth field is 


[RFC4566] with the following syntax: 


where <bwtype> is an alphanumeric modifier giving the meaning of the 


<bandwidth> figure. 


In this document, 
capability attribute "bcap". 
capabilities, 


"a=bcap:" bw-cap-num 1*WSP bwtype ":" 


we define a new capability attribute: 
This attribute lists bandwidth as 
according to the following definition: 


the bandwidth 


bandwidth CRLF 


where <bw-cap-num> is a unique integer within all the bandwidth 


capabilities in the entire SDP, 
capability and can take a value between 1 and 2%31-1 
The other elements are as defined for the 


[RFC4566]. 


which is used to number the bandwidth 
(both included). 


"b=" field in SDP 


This format satisfies the general attribute production rules in SDP 


[RFC4566], according to the following Augmented Backus-Naur Form 
(ABNF) [RFC5234] syntax: 
att-field =/ "bcap" 
att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth 
bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 
Figure 2: Syntax of the "bcap" attribute 
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Negotiation of bandwidth per media stream can be useful when 
negotiating media encoding capabilities with different bandwidths. 


3.1.1.1. Configuration Parameters 


The SDP Capability Negotiation Framework [RFC5939] provides for the 
existence of the "pcfg" and "acfg" attributes. The concept is 
extended by the SDP Media Capabilities Negotiation [RFC6871] with an 
"lcfg" attribute that conveys latent configurations. 


Extensions to the "pcfg" and "lcfg" attributes are defined through 
<extension-config-list>, and extensions to the "acfg" attribute are 
defined through the <sel-extension-config>, as defined in the SDP 
Capability Negotiation [RFC5939]. 


In this document, we extend the <extension-config-list> field to be 
able to convey lists of bandwidth capabilities in latent or potential 
configurations, according to the following Augmented Backus-Naur Form 
(ABNF) [RFC5234] syntax: 


extension-config-list =/ bandwidth-config-list 

bandwidth-config-list = ["+"] "b=" bw-cap-list *(BAR bw-cap-list) 
; BAR defined in RFC 5939 

bw-cap-list = bw-cap-num *("," bw-cap-num) 


bw-cap-num 1*10(DIGIT) ; DIGIT defined in RFC 5234 
Figure 3: Syntax of the bandwidth parameter 
in "lcfg" and "pcfg" attributes 


Each bandwidth capability configuration is a comma-separated list of 
bandwidth capability attribute numbers where <bw-cap-num> refers to 
the <bw-cap-num> bandwidth capability numbers defined explicitly 
earlier in this document, and hence MUST be between 1 and 2%31-1 
(both included). Alternative bandwidth configurations are separated 
by a vertical bar ("|"). 


The above syntax is very flexible, allowing referencing to multiple 

"b=" lines per configuration, even for the same <bwtype>. While the 
need for such definitions is not seen, we have not restricted this, 

as it is not restricted in SDP [RFC4566] either. 
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The bandwidth parameter to the actual configuration attribute 
("a=acfg") is formulated as a <sel-extension-config> with 


ext-cap-name = "b" 
hence 


sel-extension-config =/ sel-bandwidth-config 
sel-bandwidth-config = "b=" bw-cap-list ; bw-cap-list as above. 


Figure 4: Syntax of the bandwidth parameter in "acfg" attributes 
3.1.1.2. Option Tag 


The SDP Capability Negotiation Framework [RFC5939] allows for 
capability negotiation extensions to be defined. Associated with 
each such extension is an option tag that identifies the extension in 
question. Hereby, we define a new option tag "bcap-v0" that 
identifies support for the bandwidth capability. The endpoints using 
the "bcap" capability attribute SHOULD add the option tag to other 
existing option tags present in the "csup" and "creq" attributes in 
SDP, according to the procedures defined in the SDP Capability 
Negotiation Framework [RFC5939]. 


3.1.2. Connection Data Capability 


According to SDP [RFC4566], the connection data field in SDP contains 
the connection data, and it has the following syntax: 


c=<nettype> <addrtype> <connection-address> 
where <nettype> indicates the network type, <addrtype> indicates the 


address type, and the <connection-address> is the connection address, 
which is dependent on the address type. 


At the moment, network types already defined include "IN", which 
indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]), 
used for describing Asynchronous Transfer Mode (ATM) bearer 
connections. The Circuit-Switched (CS) descriptions in the SDP 
document [SDP-CS] adds a "PSTN" network type for expressing a Public 
Switched Telephone Network (PSTN) circuit switch. 


Garcia-Martin, et al. Standards Track [Page 8] 


REC 7006 SDP Misc. Capabilities Negotiation September 2013 


SDP [RFC4566] permits specification of connection data at the SDP 


session and/or media level. In order to permit negotiation of 
connection data at the media level, we define the connection data 
capability attribute ("a=ccap") in the form: 


"a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP 
connection-address CRLF 


where <conn-cap-num> is a unique integer within all the connection 
capabilities in the entire SDP, which is used to identify the 
connection data capability and can take a value between 1 and 2%31-1 
(both included). The other elements are as defined in [RFC4566]. 


This format corresponds to the [RFC4566] attribute production rules, 
according to the following Augmented Backus-Naur Form (ABNF) 
[RFC5234] syntax: 


att-field =/ "ccap" 

att-value =/ conn-cap-num 1*WSP nettype SP addrtype 
SP connection-address 

conn-cap-num = 1*10(DIGIT) ; 1 to 2%31-1, inclusive 


; DIGIT defined in RFC 5234 
Figure 5: Syntax of the "ccap" attribute 


The "ccap" capability attribute allows for expressing alternative 
connections address ("c=") lines in SDP as part of the SDP Capability 
Negotiation process. One of the primary use cases for this is 
offering alternative connection addresses where the <nettype> is "IN" 
or "PSTN", i.e., selecting between an IP-based bearer or a 
circuit-switched bearer. 


By supporting the "IN" <nettype>, the "ccap" attribute enables the 
signaling of multiple IPv4 and IPv6 addresses; however, the Standards 
Track mechanism for negotiation of alternative IP addresses in SDP is 


Interactive Connectivity Establishment (ICE) [RFC5245]. The "ccap" 
attribute does not change that; hence, the combined set of actual and 
potential configurations (as defined in [RFC5939]) for any given 


media description MUST NOT use the "ccap" attribute to negotiate more 
than one address with an IN network type (i.e., it is not permissible 
to select between "IPv4" and "IPv6" address families or different IP 
addresses within the same IP address family. 


Figure 6 is an example of an SDP offer that includes a "ccap" 


capability attribute. An audio stream can be set up with an RTP flow 
or by establishing a circuit-switched audio stream: 
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=creq:med-v0,ccap-v0 

m=audio 38902 RTP/AVP 0 8 

c=IN IP4 198.51.100.7 

a=ccap:1 PSTN E164 +15555556666 

a=tcap:2 PSTN 

a=omcap:1 - 

a=acap:1 setup:actpass 

a=acap:2 connection:new 

a=acap:3 cs-correlation:callerid:+15555556666 
a=pcfg:1 c=1 t=2 m=1 a=1,2,3 


Figure 6: Example SDP offer with a "ccap" attribute 


The example in Figure 6 represents an SDP offer indicating an audio 
flow using RTP, such as the one represented in Figure 7, or an audio 
flow using a circuit-switched connection, such as the one represented 
in Figure 8. 


0 
2987933123 2987933123 IN IP4 198.51.100.7 


0 0 
=audio 38902 RIP/AVP 0 8 
c=IN IP4 198.51.100.7 


v 
o) 
s 
t 
m 
Figure 7: Equivalent SDP offer with the RTP flow 


m=audio 9 PSTN - 

c=PSTN E164 +15555556666 
a=setup:actpass 

a=connection:new 
a=cs-correlation:callerid:+15555556666 


Figure 8: Equivalent SDP offer with the circuit-switched flow 


This document does not define any mechanism for negotiating or 
describing different port numbers; hence, the port number from the 
"m=" line MUST be used by default. Exceptions to this default can be 
provided by extension mechanisms or network type specific rules. 

This document defines an exception when the network type is "PSTN", 
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in which case the port number is replaced with 9 (the "discard" 
port), as described in "Session Description Protocol (SDP) Extension 
for Setting Audio and Video Media Streams over Circuit-Switched 
Bearers in the Public Switched Telephone Network (PSTN)" [SDP-CS]. 

An endpoint offering alternative IP and PSTN bearers MUST include the 
IP media description in the actual configuration (IP address in the 
"c=" line and port number in the "m=" line) and the PSTN media 
description in the potential configuration. 


Exceptions for other network types, such as for the "ATM" network 
type defined in [RFC3108], require additional specifications. 


3.1.2.1. Configuration Parameters 


The SDP Capability Negotiation Framework [RFC5939] provides for the 
existence of the "pcfg" and "acfg" attributes, which can convey one 
or more configurations to be negotiated. The concept is extended by 
the SDP Media Capabilities Negotiation [RFC6871] with an "lcfg" 
attribute that conveys latent configurations. 


In this document, we define a <connection-config> parameter to be 
used to specify a connection data capability in a potential or latent 
configuration attribute. The parameter follows the form of an 
<extension-config-list> with 

ext-cap-name = "c" 


ext-cap-list = conn-cap-list 


where, according to the following Augmented Backus-Naur Form (ABNF) 
[RFC5234] syntax: 


extension-config-list =/ conn-config-list 


conn-config-list = ["+"] "c=" conn-cap-list 
conn-cap-list = conn-cap-num * (BAR conn-cap-num) 
conn-cap-num = 1*10(DIGIT) ; 1 to 2%32-1 inclusive 


Figure 9: Syntax of the connection data 
parameter in "lcfg" and "pcfg" attributes 


Each capability configuration alternative contains a single 
connection data capability attribute number and refers to the 
conn-cap-num capability number defined explicitly earlier in this 
document; hence, the values MUST be between 1 and 2%31-1 (both 
included). The connection data capability allows the expression of 
only a single capability in each alternative, rather than a list of 
capabilities, since no more than a single connection data field is 
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permitted per media block. Nevertheless, it is still allowed to 
express alternative potential connection configurations separated by 
a vertical bar ("|"). 


An endpoint includes a plus sign ("+") in the configuration attribute 
to mandate support for this extension. An endpoint that receives 
this parameter prefixed with a plus sign and does not support this 
extension MUST treat that potential configuration as not valid. 


The connection data parameter to the actual configuration attribute 
("a=acfg") is formulated as a <sel-extension-config> with 


ext-cap-name = "c" 
hence 


sel-extension-config =/ sel-connection-config 
sel-connection-config = "c=" conn-cap-num ; as defined above. 


Figure 10: Syntax of the connection data parameter 
in "acfg" attributes 


3:.152.2. ¿Option Tag 


The SDP Capability Negotiation Framework [RFC5939] solution allows 
for capability negotiation extensions to be defined. Associated with 
each such extension is an option tag that identifies the extension in 
question. Hereby, we define a new option tag of "ccap-v0" that 
identifies support for the connection data capability. This option 
tag SHOULD be added to other existing option tags present in the 
"csup" and "creq" attributes in SDP, according to the procedures 
defined in the SDP Capability Negotiation Framework [RFC5939]. 


3.1.3. Title Capability 


SDP [RFC4566] provides for the existence of an information field 
expressed in the format of the "i=" line, which can appear at the SDP 
session and/or media level. An "i=" line that is present at the 
session level is known as the "session name", and its purpose is to 
convey human-readable textual information about the session. 


The "i=" line in SDP can also appear at the media level, in which 
case it is used to provide human-readable information about the media 
stream to which it is related; for example, it may indicate the 


purpose of the media stream. The "i=" line is not to be confused 
with the label attribute ("a=label:", [RFC4574]), which provides a 
machine-readable tag. It is foreseen that applications declaring 


capabilities related to different configurations of a media stream 
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may need to provide different identifying information for each of 
those configurations. That is, a party might offer alternative media 
configurations for a stream, each of which represents a different 
presentation of the same or similar information. For example, an 
audio stream might offer English or Spanish configurations, or a 
video stream might offer a choice of video source such as speaker 
camera, group camera, or document viewer. The title capability is 
needed to inform the answering user in order to select the proper 
choice, and the label is used to inform the offering machine which 
choice the answerer has selected. Hence, there is value in defining 
a mechanism to provide titles of media streams as capabilities. 


As defined in SDP [RFC4566], the session information field ("i=", 
referred to as "title" in this document) is subject to the 
"a=charset" attribute in order to support different character sets 
and hence internationalization. The title capability attribute 
itself ("a=icap") is, however, not subject to the "a=charset" 
attribute as this would preclude the inclusion of alternative 
session/title information each using different character sets. 
Instead, the session/title value embedded in an "a=icap" attribute 
(title capability) will be subject to the "a=charset" value used 
within a configuration that includes that title capability. This 
provides for consistent SDP operation while allowing for capabilities 
and configurations with different session/title information values 
with different character set encodings (with each such configuration 
including an "a=charset" value with the relevant character set for 
the session/title information in question). 


According to SDP [RFC4566], the session information ("i=") line has 
the following syntax: 


"i=" text 


where "text" represents a human-readable text indicating the purpose 
of the session or media stream. 


In this document, we define a new capability attribute: the title 
capability "icap". This attribute lists session or media titles as 
capabilities, according to the following definition: 


"a=icap:" title-cap-num 1*WSP text 


where <title-cap-num> is a unique integer within all the connection 
capabilities in the entire SDP, which is used to identify the 
particular title capability and can take a value between 1 and 2%31-1 
(both included). <text> is a human-readable text that indicates the 
purpose of the session or media stream it is supposed to 
characterize. 
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As an example, one might use: 
a=icap:1 Document Camera 


to define a title capability number 1 to identify a particular source 
of a media stream. 


Or, in another example, one might offer two title capabilities with 
different character encodings (using the charset attribute defined in 
"SDP: Session Description Protocol" [RFC4566] and the generic 
attribute capability attribute ("a=acap:") defined in "Session 
Description Protocol (SDP) Capability Negotiation" [RFC5939]). 


a=icap:1 [Text encoded in ISO-8859-1] 
a=acap:1 charset:IS0-8859-1 

a=icap:2 [Text encoded in UTF-8] 
a=acap:2 charset:UTF-8 


NOTE: Due to limitations of the ASCII encoding of RFCs, the actual 
text with non-printable characters cannot be represented in the text. 
See the PDF format of this RFC for a figure with non-printable 
characters. 


The title capability attribute satisfies the general attribute 
production rules in SDP [RFC4566], according to the following 
Augmented Backus-Naur Form (ABNF) [RFC5234] syntax: 


att-field =/ "icap" 
att-value =/ title-cap-num 1*WSP text 

; text defined in RFC 4566 
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 


Figure 11: Syntax of the "icap" attribute 
3.1.3.1. Configuration Parameters 
The SDP Capability Negotiation Framework [RFC5939] provides for the 
existence of the "pcfg" and "acfg" attributes. The concept is 


extended by the SDP Media Capabilities Negotiation [RFC6871] with an 
"lcfg" attribute that conveys latent configurations. 
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In this document, we define a <title-config-list> parameter to be 

used to convey title capabilities in a potential or latent 

configuration. This parameter is defined as an 

<extension-config-list> with the following associations: 
ext-cap-name = "i" 


ext-cap-list = title-cap-list 


This leads to the following definition for the title capability 
parameter: 


extension-config-list =/ title-config-list 


title-config-list = ["+"] "i=" title-cap-list 
title-cap-list = title-cap-num * (BAR title-cap-num) 

; BAR defined in RFC 5939 
title-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 


Figure 12: Syntax of the title capability parameter 
in "lcfg" and "pcfg" attributes 


Each potential capability configuration contains a single title 
capability attribute number where "title-cap-num" is the title 
capability number defined explicitly earlier in this document, and 
hence must be between 1 and 2%31-1 (both included). The title 
capability allows the expression of only a single capability in each 
alternative, since no more than a single-title field is permitted per 
block. Nevertheless, it is still allowed to express alternative 
potential title configurations separated by a vertical bar œ|"). 


An endpoint includes a plus sign ("+") in the configuration attribute 
to mandate support for this extension. An endpoint that receives 
this parameter prefixed with a plus sign and does not support this 
extension MUST treat that potential configuration as not valid. 


The title parameter to the actual configuration attribute ("a=acfg") 
is formulated as a <sel-extension-config> with 


ext-cap-name = "i" 
hence 


sel-extension-config =/ sel-title-config 
sel-title-config = "i=" title-cap-num ; as defined above. 


Figure 13: Syntax of the title parameter in "acfg" attributes 
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3.1.3.2. ¿Option Tag 


At present, it is difficult to envision a scenario in which the 
"icap" attribute must be supported or the offer must be rejected. In 
most cases, if the icap attribute or its contents were to be ignored, 
an offered configuration could still be chosen based on other 
criteria such as configuration numbering. However, one might imagine 
an SDP offer that contained English and Spanish potential 
configurations for an audio stream. The session might be 
unintelligible if the choice is based on configuration numbering, 
rather than informed user selection. Based on such considerations, 
it may well prove useful to announce the ability to use the icap 
attribute and its contents to select media configurations, or to 
inform the user about the selected configuration(s). Therefore, we 
define a new option tag of "icap-v0" that identifies support for the 
title capability. This option tag SHOULD be added to other existing 
option tags present in the "csup" and/or "creq" attributes in SDP, 
according to the procedures defined in the SDP Capability Negotiation 


Framework [RFC5939]. The discussion above suggests that "icap-v0" 
will typically appear in a "csup" attribute, but rarely in a "creq" 
attribute. 

3.2. Session Level versus Media Level 


The "bcap", "ccap", and "icap" attributes can appear at the SDP 
session and/or media level. Endpoints MUST interpret capabilities 
declared at session level as part of the session level in the 
resulting SDP for that particular configuration. Endpoints MUST 
interpret capabilities declared at media description as part of the 
media level in the resulting SDP for that particular configuration. 


The presence of the "bcap" capability for the same <bwtype> at both 
the session and media level is subject to the same constraints and 
restrictions specified in RFC 4566 [RFC4566] for the bandwidth 
attribute "b=". 


To avoid confusion, the <type-attr-num> for each "a=bcap", "a=ccap", 


and "a=icap" line MUST be unique across all capability attributes of 
the same type within the entire session description. 
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3.3. Offer/Answer Model Extensions 


In this section, we define extensions to the offer/answer model 
defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP 
Capability Negotiation [RFC5939] to allow for bandwidth, connection, 
and title capabilities to be used with the SDP Capability Negotiation 
Framework. 


3.3.1. Generating the Initial Offer 


When an endpoint generates an initial offer and wants to use the 
functionality described in the current document, it first defines 
appropriate values for the bandwidth, connection data, and/or title 
capability attributes according to the rules defined in [RFC4566] for 
"b=", "c=", and "i=" lines. The endpoint then MUST include the 
respective capability attributes and associated values in the SDP 
offer. The preferred configurations for each media stream are 
identified following the media line in a "pcfg" attribute. Bandwidth 
and title capabilities may also be referenced in latent 
configurations in an "lcfg" attribute, as defined in the SDP Media 
Capabilities Negotiation [RFC6871]. 


Implementations are advised to pay attention to the port number that 
is used in the "m=" line. By default, a potential configuration that 
includes a connection data capability will use the port number from 
the "m=" line, unless the network type is "PSTN", in which case the 
default port number used will be 9. 


The offer SHOULD include the level of capability negotiation 
extensions needed to support this functionality in a "creq" 
attribute. 


3.3.2. Generating the Answer 


When the answering party receives the offer, and if it supports the 
required capability negotiation extensions, it SHOULD select the most 
preferred configuration it can support for each media stream and 
build the answer accordingly, as defined in Section 3.6.2 of the SDP 
Capability Negotiation [RFC5939]. 


If the connection data capability is used in a selected potential 
configuration chosen by the answerer, that offer configuration MUST 
by default use the port number from the actual offer configuration 
(i.e., the "m=" line), unless the network type is "PSTN", in which 
case the default port MUST be assumed to be 9. Extensions may be 
defined to negotiate the port number explicitly instead. 
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3.3.3. Offerer Processing of the Answer 


When the offerer receives the answer, it MUST process the media lines 
according to normal SDP processing rules to identify the media 
stream(s) accepted by the answer, if any, as defined in Section 3.6.3 
of the SDP Capability Negotiation [RFC5939]. The "acfg" attribute, 
if present, MUST be used to verify the proposed configuration used to 
form the answer and to infer the lack of acceptability of 
higher-preference configurations that were not chosen. 


3.3.4. Modifying the Session 


If, at a later time, one of the parties wishes to modify the 
operating parameters of a session, e.g., by adding a new media stream 
or by changing the properties used on an existing stream, it may do 
so via the mechanisms defined for SDP offer/answer [RFC3264] and in 
accordance with the procedures defined in Section 3.6.4 of the SDP 
Capability Negotiation [RFC5939]. 


4. Field Replacement Rules 


To simplify the construction of SDP records, given the need to 
include fields within the media description in question for endpoints 
that do not support capabilities negotiation, we define some simple 
field-replacement rules for those fields invoked by potential or 


latent configurations. In particular, any "i=" or "c=" lines invoked 
by a configuration MUST replace the corresponding line, if present 
within the media description in question. Any "b=" line invoked by a 


configuration MUST replace any "b=" of the same bandwidth type at the 
media level, but not at the session level. 


5. Security Considerations 


This document provides an extension on top of the SDP [RFC4566], SDP 
Offer/Answer Model [RFC3264], SDP Capability Negotiation Framework 
[RFC5939], and SDP Media Capabilities Negotiation [RFC6871]. As 
such, the security considerations of those documents apply. 


The bandwidth capability attribute may be used for reserving 
resources at endpoints and intermediaries that inspect SDP. 
Modification of the bandwidth value by an attacker can lead to the 
network being underutilized (too high bandwidth value) or congested 
(too low bandwidth value). 
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Similarly, by modifying the alternative connection address (es), an 
attacker would be able to direct media streams to a desired endpoint, 
thus launching a version of the well-known voice hammer attack (see 
Section 18.5.1 of [RFC5245]). 


The title capability provides for alternative "i=" line information, 
which is intended for human consumption. However, manipulating the 
textual information could be misused to provide false information, 
leading to a bad user experience or the person using the service 
making a wrong choice regarding the available media streams. 


In case it is essential to protect the capability attribute values, 
one of the security mechanisms proposed in [RFC5939] SHOULD be used. 


The "i=" line, and thus the value carried in the title capability 
attribute, is intended for human-readable description only. It 
should not be parsed programmatically. 

6. IANA Considerations 


6.1. New SDP Attributes 


IANA has registered new attributes in the "att-field (both session 


and media level)" subregistry of the "Session Description Protocol 
(SDP) Parameters" registry, according to the following registration 
form: 

Attribute name: bcap 

Long form name: Bandwidth Capability 

Type of attribute: Both media and session level 

Subject to charset: No 

Purpose: Negotiate session or media-level bandwidths 

Appropriate values: See RFC 7066, Section 3.1.1 

Contact name: Miguel A. Garcia 


Miguel.A.Garcia@ericsson.com 


Attribute name: ccap 

Long form name: Connection Data Capability 

Type of attribute: Both media and session level 

Subject to charset: No 

Purpose: Negotiate media-level connection data 
Appropriate values: See RFC 7066, Section 3.1.2 

Contact name: Miguel A. Garcia 


Miguel.A.Garcia@ericsson.com 
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Attribute name: icap 

Long form name: Title Capability 

Type of attribute: Both media and session level 

Subject to charset: Yes 

Purpose: Negotiate human-readable information 


describing the session or media 
Appropriate values: See RFC 7066, Section 3.1.3 
Contact name: Miguel A. Garcia 

Miguel.A.Garcia@ericsson.com 


6.2. New Option Tags 


IANA has added the new option tags "bcap-v0", "ccap-v0", and "icap- 
v0", defined herein, to the "SDP Capability Negotiation Option Tag" 
subregistry of the "Session Description Protocol (SDP) Parameters" 
registry. 


6.3. New SDP Capability Negotiation Configuration Parameters 


IANA has added the new parameter identifiers "b" for "Bandwidth", "c" 
for "Connection Data", and "i" for "Title" to the "SDP Capability 
Negotiation Configuration Parameters" subregistry of the "Session 
Description Protocol (SDP) Parameters" registry. These parameters 
are permitted in "lcfg", "acfg", and "pcfg" attributes. 
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